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10 NETWORK REVERSE AUCTION AND 

SPENDING ANALYSIS METHODS 

Technical Field 

15 This application relates to computer assisted methods for preparation of 

requests for proposals (RFP), dissemination of RFPs to vendors, collection of vendor 
proposals in an online reverse auction environment, analysis and selection of vendors, 
and analysis of spending; and, in particular, to such methods for use in bidding and 
contracting for telecommunications services, analysis of telecommunications 

20 spending, and management of telecommunications usage. 
Background of the Invention 

Large corporations and other major users of telecommunications services often 
spend hundreds of millions of dollars on such services annually. These customers 
commonly use multiple telecommunications carriers to provide the services required 

25 for various types of traffic, such as, for example, voice, cellular, paging, and data 

transmission. Additional telecommunications carriers may be used for certain classes 
of service, such as calls and other traffic between specific locations or at certain 
times. Furthermore, multiple telecommunications carriers are commonly used for the 
exact same class of service, for purposes of introducing redundancy in the customer's 

30 telecommunications resources, and for other reasons. As used herein, the term "class 
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of service" means a particular telecommunications service for transmitting voice, 
data, or other signals between two geographic locations. Each different type of traffic 
transmitted and each different origination and destination region for the traffic may 
constitute a unique class of service. Class of service definitions are primarily 
5 dependent upon how telecommunications carriers distinguish traffic for the purpose of 
applying different rates. 

Large telecommunications customers typically employ analysts who review 
billing statements, perform audits, and request new telecommunications installation 
and services for the entire organization. Telecommunications analysts monitor the 

10 customer's telecommunications spending to identify overcharges and mistakes made 
by service providers and to minimize expenditures generally. To perform these tasks, 
the analyst reviews the detailed billing statements provided by carriers. Carriers 
commonly provide bills on a monthly basis in a computer-readable format, such as a 
CD-ROM, but may use other formats, such as paper, magnetic tape, EDI, and the 

15 World Wide Web. 

Analyzing telecommunications billing statements can be burdensome due to the 
volume of information they include. This is especially true when multiple carriers are 
used, because the carriers do not typically use the same billing format or provide the 
same kinds of traffic information. Different carriers may also use different service 

20 class codes to identify the same class of telecommunications service, making it 

difficult to compare competitor rates. Furthermore, the data included in computer- 
readable billing statements may be stored in a nonstandard database format or may 
require special bill viewing software that is unique to the carrier. Due to the volume 
of call data and the different data formats, it is often too burdensome for an analyst to 

25 track all telecommunications traffic on a monthly basis. Consequently, many choose 
to merely perform audits in an attempt to avoid gross carrier overcharges and 
mistakes. Thus, a need exists for an improved method of monitoring and analyzing 
telecommunications spending. 

Large telecommunications customers use their buying power to negotiate 

30 telecommunications services contracts having a desired balance of competitive rates 
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and service plan features. To begin the negotiation process, historical call data is 
typically gathered by the customer, e.g. , from past bills, and used to help forecast 
telecommunications needs for the duration of the proposed contract term. Since 
different telecommunications carriers deliver computer-readable billing data in 
5 different formats, the task of compiling historical use summaries and forecasting 

traffic is highly burdensome for a large company, especially a global company dealing 
in various languages and currencies. A large company may spend weeks or months 
compiling the necessary information and preparing telecommunications forecasts. 
To further complicate the forecasting process, the information provided in 

10 carriers' standard billing formats make it very difficult to determine the actual rates 

applied to particular traffic. For example, a contract between a customer and a single 
carrier may specify 150 different rates for hundreds of different classes of voice 
traffic. Service contracts may also specify discounts applicable to only a few of the 
contract rates in particular circumstances, such as when a volume exceeds a 

15 predetermined target. Voice traffic classes may differentiate telecommunications 
traffic based on origination location, termination location, whether the traffic was 
incoming or outgoing, the time of the traffic event, and the rate schedule to be 
applied. Rates for a particular call may even vary during the duration of the call. 
However, service class designators are not typically listed in the billing formats used 

20 by most carriers. Also, while the service contract may clearly define the applicability 
of discounts, carrier bills often fail to clearly identify calls to which the discounts 
have been applied. Consequently, summarizing and analyzing billing information is a 
complicated task. 

Once summary information has been gathered, the customer uses it to prepare 
25 a traffic forecast including the desired classes of service and anticipated quantity of 
traffic per class of service. The forecast telecommunications needs are then set forth 
in a request for proposals (RFP) that is distributed to potential telecommunications 
vendors. While the customer will typically seek the most competitive rates, other 
terms unrelated to rates may also be important. For example, the RFP may specify 
30 nonprice service plan features desired by the customer, such as the contract duration, 
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renewal period, quality of service, refund policy, warranties, customer service 
response time, customer service escalation procedures, multilingual support services, 
e-mail response services, exclusivity terms, discounts, installation fees, risk 
allocation, contract renewal terms, and/ or termination conditions. In response to the 
5 RFP, each interested vendor prepares a detailed proposal that represents a bid for the 
services or a portion thereof. Using traditional telecommunications RFP methods, the 
bidding period typically lasts a month or more. During the bidding period, each 
interested vendor submits a single proposal that represents the bidder's best shot at 
winning the business. Such proposals commonly include significant amounts of sales 

10 and advertising information, extensive legal terms, variations on the requested service 
(substitutions), and other details that make the proposal difficult to evaluate. For 
example, three proposals made in response to a medium size RFP valued at about $12 
million recently took a team of 20 people an entire month to review and extract 
relevant bid information. The burden of the RFP process prompts many large 

15 telecommunications customers to hire independent consultants skilled in preparing 
RFPs and evaluating vendor proposals. 

Once the vendor proposals have been collected and analyzed, the customer 
must choose one or more of the vendors to provide services to meet its 
telecommunications needs. Finalizing a service contract may involve negotiation and 

20 fine tuning of certain proposed contract terms. 

To guarantee competitive rates, telecommunications services contracts may 
include minimum usage or spending commitments during the term of the contract. 
Such contract provisions impose penalties on customers that fail to meet the minimum 
use commitments. Once a contract is in place, a customer will want to monitor use 

25 relative to the minimum use commitments for budgeting purposes and to take 
corrective action (in addition to monitoring for overcharges and mistakes, as 
described above). If multiple carriers are used for the same type or class of service, 
the customer may be able to offset projected usage deficits under a contract with a 
first carrier by redirecting surplus call traffic from a second carrier. Some contracts 
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may also allow rate adjustments to be made during their term. In some cases, the 
customer may be able to renegotiate the contract to avoid significant penalties. 

Telecommunications rates have declined in recent years and are expected to 
continue dropping. The potential cost reductions made possible by downward market 
5 movement can justify incurring the expense of the RFP and contract negotiation 

process on a regular basis. The frequency by which a customer should put its traffic 
up for bid is partly a function of the rate at which the market is moving and the 
expense of the RFP process. Monitoring of usage can help the customer to determine 
when to next put its telecommunications traffic up for bid. In recent years, major 
10 telecommunications users have engaged in the RFP and contract negotiation process 
once every 12 to 36 months, although many would do so more frequently if the RFP 
process required less effort and expense. 

Thus, a need exists for methods and systems for reducing the cost of the RFP 
process so that telecommunications customers can afford to put traffic up for bid more 
15 frequently. A need also exists for an improved method of monitoring 

telecommunications usage and costs relative to the market prices, to thereby improve 
the timing of the RFP process and reduce telecommunications spending. 
Summary of the Invention 

In accordance with the present invention, a telecommunications spending 
20 analysis system involves computer software that extracts telecommunications traffic 
data from computer-readable billing statements provided by telecommunications 
carriers. The spending analysis system includes a predefined traffic classification 
conversion table that is used by the system to convert each carrier's 
telecommunications traffic detail to a generic billing data format. The generic billing 
25 data format allows the traffic details of different carriers' bills to be aggregated in a 
uniform customer traffic history database that can then be sorted and summarized as 
desired by the user. 

The spending analysis system allows the user to summarize rates for each 
carrier based on the class of service provided. To help the user determine when to 
30 put its telecommunications traffic up for bid, the system preferably includes an RFP 
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timing module that compares the user's actual rates to estimated market rates listed in 
a Best of Class (BOC) database. The BOC database includes commodity designations 
representing various classes of service and estimated market rate stored in association 
with the commodity designations. The estimated market rates can be kept current by 
5 manual updates or by the RFP and market database updating method described below. 
The BOC database is made available to users of the spending analysis system, 
preferably over the Internet via a subscription-based web site and only to the extent 
necessary to allow the user to compare rates for specific service classes included on 
the user's bills. By comparing the customer's actual telecommunications rates to the 
10 estimated market rates of the BOC database, the system facilitates efficient timing of 
the RFP process. The RFP timing module can be configured to notify the user when 
the projected cost savings attributable to current reductions in service rates is likely to 
outweigh the expense of the RFP and contract negotiation process. 

In another aspect of the present invention, a method and system for preparing 

15 an RFP, collecting vendor proposals in an online reverse auction environment, and 
analyzing vendor proposals involves an interactive RFP web site. The RFP web site 
includes a secure customer account accessible by the customer for preparing an RFP 
by merely completing a web-based customer needs assessment and service level 
agreement (SLA) questionnaire. The RFP web site receives historical use data from 

20 the user, preferably by uploading it from the uniform customer traffic history database 
as created by the telecommunications spending analysis system. If the uniform 
customer traffic history database is unavailable, the customer can manually input 
historical use data. The RFP web site then uses the historical use data to 
automatically prepare a traffic forecast that the user can review and modify. The 

25 traffic forecast forms the core of the customer needs assessment. The customer also 
answers a series of predefined questions that establish the terms of a preferred SLA 
for the requested services, including non-price contract terms such as customer 
service levels, contract duration, and other non-price factors. After the customer has 
completed the customer needs assessment and SLA questions, the RFP system creates 

30 a web-based RFP response form that includes a series of predefined RFP questions 
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grouped in sections. By default, the RFP web site assigns to each of the RFP 
questions and sections a weighting factor that represents the importance of each of the 
RFP questions and sections to the customer's decision process. These weighting 
factors are adjustable by the customer. 
5 The customer is also prompted by the RFP system to identify potential vendors 

who will be invited to participate in bidding on the RFP. A reference checking 
subsystem of the RFP system may be activated by the customer for obtaining 
information about the potential vendors. The reference checking subsystem requires 
the potential vendors to supply the names and email addresses of one or more 

10 reference individuals. An email request is then automatically generated by the 

reference checking subsystem and sent to the reference individuals. The email request 
asks the reference individuals to access the reference checking subsystem and provide 
feedback on the potential vendor. As part of the RFP preparation process, the 
reference checking subsystem prompts the customer to select and/or define reference 

15 feedback questions that will be displayed to the reference individuals when they access 
the RFP system to provide feedback. As with the RFP questions, the customer can 
weight the reference feedback questions so that the reference individuals' answers to 
them will be included in the evaluation of vendor bids. 

After the RFP preparation process is complete, the RFP response form is 

20 made available to the potential vendors via a secure RFP web server that includes a 
reverse auction environment. An account name and password is assigned to each 
potential vendor to ensure access to the reverse auction is by invitation only. The 
password access allows vendor proposals to be submitted in a secure manner and 
made available only to the customer. Interested vendors submit their proposals by 

25 completing the RFP questions on the customer-defined RFP response form and 

entering proposed rates for the classes of telecommunications traffic that are up for 
bid. Because proposals must be submitted in an online forms environment, they are 
relatively uniform, which allows them to be easily summarized, evaluated, and 
transmitted by the customer. The on-line reverse auction environment can also 

30 facilitate interaction between interested vendors and the customer via email or an 
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electronic bulletin board, for clarification of the RFP and tailoring of responses to the 
customer's needs. 

The reverse auction environment enables the RFP system to provide feedback 
to bidders by comparing their bid proposals to those of other bidders. To promote 
5 competitive bidding between interested vendors, the customer may choose to have the 
RFP system rank the vendors' bids against those of other interested vendors and to 
display the rankings to the interested vendors. Each vendor may submit multiple bids 
during the auction in an attempt to improve its ranking relative to other vendors. 
During the course of the auction, interested vendors can access, modify, and resubmit 

10 a previous bid. An interested vendor can also monitor the status of the auction in real 
time to determine whether to submit a modified bid. To this end, an email 
notification subsystem can be used to notify interested vendors when they have been 
outbid by another interested vendor. 

In another aspect of the present invention, a method of updating the BOC 

15 database is integrated with the RFP system and reverse auction environment. Upon 
completion of each reverse auction, the system can update the BOC database with the 
best bid made during the auction for each class of service. In updating the BOC 
database, the method involves evaluating the age of the estimated market price data 
stored in the BOC database to determine whether an update is appropriate. Since rate 

20 information may be volume dependent, the BOC database can include best rate 

information for several different ranges of traffic volumes. The BOC database can 
also include best non-price contract terms and conditions, such as contract duration 
and service levels. 

In yet another aspect of the invention, the RFP systems and methods described 
25 above are applied to purchase and analyze usage of commodities other than 

telecommunications services. As used herein, "commodities" means products, 
services, or a combination thereof. For example, products such as computers, 
networking devices, telephones, and office equipment may be included in the RFP for 
bidding by interested vendors. Because some vendors sell both telecommunications 
30 services and other products (telephones, switches, etc.), the RFP system can also be 
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used for soliciting bids on packages of telecommunications services and other 
products. 

Additional aspects and advantages of this invention will be apparent from the 
following detailed description of preferred embodiments thereof, which proceeds with 
5 reference to the accompanying drawings. 

Brief Description of the Drawings 

Fig. 1 is a diagram illustrating a telecommunications contracting life cycle in 
accordance with the present invention; 

Fig. 2 is a schematic diagram showing the components of a 
10 telecommunications spending analysis system in accordance with the present 
invention; 

Fig. 3 is a flow diagram depicting the steps involved in using the 
telecommunications spending analysis system of Fig. 2; 

Fig. 4 is a schematic diagram showing the components of an RFP system in 
15 accordance with the present invention; and 

Figs. 5 and 6 are flow diagrams depicting a method of preparing an RFP, 
conducting a reverse auction, and updating a Best of Class database using the RFP 
system of Fig. 4. 

Detailed Description of Preferred Embodiment 
20 Fig. 1 is a diagram illustrating a telecommunications contracting life cycle in 

accordance with the present invention. With reference to Fig. 1, a 
telecommunications customer first analyzes its spending 101 using an automated 
telecommunications spending analysis system 200 (Fig. 2). The customer puts its 
traffic up for bid, when desired, by preparing a request for proposals (RFP) and 
25 soliciting bids from interested vendors in a reverse auction environment 102. In the 
preferred embodiment, described in detail below, the reverse auction environment is 
implemented for remote access via the Internet using a web browser. Once the RFP 
web auction is complete, the customer selects a vendor and implements a contract 
103. Following contract implementation, the customer audits bills for compliance 
30 with the contract terms 104. Thereafter, the customer completes the 



Portlnd2-4286130v4 44892-003:1 

10 

telecommunications contracting life cycle by resuming automated analysis of its 
spending. 

Spending Analysis System 

Fig. 2 is a schematic diagram of a telecommunications spending analysis 
5 system 200 in accordance with a preferred embodiment of the present invention. 

With reference to Fig. 2, spending analysis system 200 includes a web server 202 that 
serves as a front end to a customer traffic history database 204 and a best of class 
database 206 (BOC database). Web server 202 includes software for generating web 
pages; for querying databases 204, 206; and for updating databases 204, 206. In an 
10 alternative embodiment (not shown), spending analysis system 200 includes a data 

server that serves as a back end of the system for handling database queries from web 
server 202; serving data to web server 202; and updating databases 204, 206 in 
response to update requests from web server 202. Web server 202 is connected to a 
network 210 such as the Internet to allow remote access by customers. An analysis 

15 software module operates on a customer computer 212 for extracting billing data from 
carrier bills 214, which are received from the customer's telecommunications carriers 
in various formats and on various media, such as CD-ROM, magnetic media, and 
paper. Customer computer 212 is preferably a personal computer running the 
Windows operating system, but other types of personal computers and other types of 

20 general purpose computers capable of operating a web browser can also be used. 

As described above in the Background of the Invention section, carrier bills 
typically include the customer's telecommunications traffic detail in a special or 
proprietary format that is readable by bill viewing software provided by the carrier. 
Often the bill viewing software is a self-launching program that is included on the 

25 same disk with the billing data itself. 

Fig. 3 is a flow diagram depicting a method 300 in accordance with the 
present invention for extracting, summarizing, and analyzing carrier bills 214 using 
spending analysis system 200 of Fig. 2. With reference to Figs. 2 and 3, a 
telecommunications customer runs the analysis software on customer computer 212. 

30 The analysis software reads telecommunications traffic detail data from carrier bills 
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214 (step 302). Preferably, the analysis software reads traffic detail data directly 
from the billing CDs and disks, but can also be configured to access the billing data 
using components of the carriers' custom bill viewing software as middleware. If ttie 
analysis software encounters an unknown data format or traffic type code in the 
5 carrier bill, it will prompt the user to install an updated version of the analysis 

software (step 304), which may be available for download from web server 202. To 
facilitate maintenance of the analysis software, unknown data formats and type codes 
cause the software to launch an error reporting routine (step 306) that reports errors to 
software development personnel who are responsible for telecommunications spending 
10 analysis system 200. In an alternative embodiment (not shown), the analysis software 
can be configured to automatically report data extraction errors via web server 202 
for review by software development personnel. 

A traffic genericizing module of the analysis software converts extracted 
billing data to a generic traffic format according to a set of translation rules (step 
15 308). A different set or subset of translation rules is generally applicable to each 

vendor, such as, for example, AT&T™, MCI™, and SPRINT™. The translation rules 
relate billed traffic detail data to the generic traffic format based on a class of service 
of each traffic event. The class of service of each traffic event can be ascertained 
from the following four pieces of information, which can be obtained from the billing 
20 detail: (1) whether the traffic is incoming or outgoing, (2) the type of service (e.g. , 
voice, data, paging, cellular), (3) the boundary type (e.g. , interstate, inter-LATA, 
international), and (4) the rate schedule applicable to the service. The translation 
rules are preferably defined in the analysis software itself, but could also be stored 
remotely, for example, on web server 202 of spending analysis system 200. 
25 Once translated to the generic format, the traffic detail can be summarized, 

sorted, combined with data from other carriers, and compared to estimated market 
rates available from BOC database 206. The analysis software allows the user to 
display and manipulate the generic customer traffic history data in a variety of ways 
(step 310). Conversion of the billing data to the generic format is necessary because 
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data from different carriers, if aggregated in its original format, cannot be 
manipulated or compared to market rates. 

The analysis software can also estimate when the traffic should be put up for 
bid (step 312) by comparing the customer's rates and traffic volume to the estimated 
5 market rates on BOC database 206 and then weighing the potential benefit of 

decreased rates against the cost of engaging in the RFP process. If efficiencies are 
predicted by the analysis software, it can automatically notify the user of the 
opportunity to reduce costs by putting its traffic up for bid (step 314). 

In addition to analyzing traffic data for rate information, the analysis software 
10 can be configured to monitor the customer's compliance with various 

telecommunications contract terms. For example, if a contract specifies that the 
customer must use a minimum target quantity of a particular class of service in order 
for a discounted rate to apply, the analysis software can be configured by the user to 
monitor whether it is on track for meeting or exceeding the volume target. If a 

15 projected deficit on one carrier is identified by the analysis software, it will suggest 
rerouting of surplus traffic from another carrier (step 316). Because the analysis 
software monitors traffic over multiple carriers, it can also suggest strategies for 
rerouting traffic to take advantage of special rates for maximum efficiency. 
Algorithms in accordance with known practices are included in the analysis software 

20 for minimizing costs on the basis of these and other factors. 

The analysis software can also monitor whether new services initiated during 
the billing period were installed and billed in accordance with contract terms 
(step 318). For example, a contract may specify that digital subscriber lines (DSL) 
are to be installed for a fixed fee and thereafter be subject to a special rate. However, 

25 when ordering the DSL line the customer must reference the contract in order to be 
eligible for the fixed installation fee and special rate. In this example, the analysis 
software can be configured to monitor whether the price of new DSL installations 
exceeds the contract price. If so, then the customer is notified so that it can take 
corrective action. The analysis software can also be configured to send a message to 

30 the carrier identifying the installation fee discrepancy and requesting correction. 
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Under some contracts, the customer can work with the carrier to rectify the error, but 
only if it is identified within a certain period of time. The analysis software thus 
facilitates timely identification and correction of service order errors. 

Periodically, the traffic detail extracted from carrier bills 214 by customer 
5 computer 212 is transferred to customer traffic history database 204 for centralized 
storage and analysis (step 320). The customer's traffic history data is thus always 
available and conveniently ready for use in an RFP system 400 (Fig. 4), described 
below. 

In a second preferred embodiment analysis system (not shown), customers 
10 authorize their telecommunications carriers to send traffic detail directly to a 

centralized traffic history database service. The traffic data may be sent electronically 
via EDI, FTP, HTTP, XML, or otherwise; or delivered on a data storage medium for 
uploading to customer traffic history database 204. The participating customer can 
then access and analyze its traffic data via network 210 by accessing a secure account 
15 on a web site hosted on web server 202. 

RFP System and Auction 
Fig. 4 is a schematic diagram showing the components of a preferred 
embodiment RFP system 400 in accordance with the present invention. With 
reference to Fig. 4, RFP system 400 is similar in arrangement to spending analysis 
20 system 200, in that it includes an RFP web server 402, a customer traffic history 

database 404, and a Best of Class (BOC) database 406 all accessible over a network 
410, such as the Internet. Additionally, RFP system 400 includes an RFP database 
408 for storing information pertaining to the RFP process. For clarity, the databases 
204, 206, 404, 406, and 408, are all shown separately. However, it will be 
25 understood by those skilled in the art that the databases 204, 206, 404, 406, and 408 
could easily be combined in a single database, on multiple databases stored on the 
same computer system, or distributed to different computers for access over networks 
210, 410. RFP web server 402 can be integrated with web server 202 or 
implemented on a separate computer in communication with web server 202 over a 
30 network. In a preferred embodiment, RFP system 400 is combined with spending 
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analysis system 200. As described below, RFP system 400 is accessible over network 
410 using a customer computer 412 to create and release an RFP using RFP web 
server 402. Customer computer 412 may include software, such as the analysis 
software of spending analysis system 200, for extracting traffic data from carrier bills 
5 414 and uploading it to customer traffic history database 404 for use in the RFP 

preparation process described below. Once an RFP has been set up and released for 
bidding, vendors can access RFP web server 402 via network 410. 

Fig. 5 is a flow diagram depicting a preferred method of preparing an RFP, 
conducting a reverse auction, and updating BOC databases 206, 406 using RFP 

10 system 400 of Fig. 4. With reference to Fig. 5, the customer begins an RFP process 
500 by inputting a traffic needs forecast and completing a service level agreement 
(SLA) questionnaire (step 502). The traffic needs forecast can be based on historical 
traffic data uploaded from customer traffic history database 404, which may comprise 
customer traffic history database 204 updated in connection with use of spending 

15 analysis system 200. 

Fig. 6 is a flow diagram detailing step 502 of Fig. 5, the steps by which the 
customer inputs the RFP traffic forecasts and SLA questions using RFP system 400. 
With reference to Fig. 6, the customer begins the input process by signing on to RFP 
web server 402 using a user name and password (step 602). The customer then enters 

20 contact information, including an email address for the person to contact in connection 
with the RFP process (step 604). RFP web server 402 prompts the customer to input 
a traffic use forecast, either manually (not shown) or by uploading historical traffic 
data from customer traffic history database 404 (step 606). The customer can then 
select particular classes of service to include in the reverse auction (step 608). By 

25 default, RFP web server 402 calculates an annual traffic use forecast based on the past 
year of the client's use of the selected class of service. Alternatively, RFP web server 
402 can adjust the forecast over past use based on a user-defined growth factor. 

After the traffic forecast has been completed (step 608), RFP system 400 
prompts the customer to select predefined groups of SLA questions called "sections" 

30 (step 610) and to input "answers" to SLA questions in the selected sections (step 
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612). "Answering" the SLA questions may involve merely selecting or deselecting 
predefined questions for inclusion in or exclusion from the RFP. The sections, which 
may be divided into subsections of SLA questions, are then weighted by the customer 
(step 614), for example, by selecting an importance factor ranging from 1 to 5. 
5 Individual SLA questions may also be weighted by selecting an importance factor 

ranging from 1 to 5. Examples of sections are "Account Management" and "General 
Terms and Conditions." Subsections within the Account Management section might 
include, for example, "Contract Implementation" and "Ongoing Customer Support." 
SLA questions in Account Management/Ongoing Customer Support subsection might 
10 include the following questions, for example: 

"a. Will you provide a dedicated Account Team that will 
service all of Customer's needs for the duration of the contract? 

"b. Will you also provide a single point of contact responsible 
for overall management of the service? 
15 "c. Do you agree to provide a response to each and every 

Customer-generated e-mail within 24 hours? 

"d. Will you provide live telephone answering which originates 
within each Supplier contact's office? 

"e. Will you provide live operator access via dialing zero at 
20 any point in a voice mail or auto-attendant prompt? 

"f. Will you provide multi-lingual support to all Customer sites 
24 hours/day, 7 days/ week? 

"g. Will you provide an escalation list for ongoing Customer 
support, including contact names, titles, direct office phone numbers, 
25 mobile phone numbers, pager numbers, e-mail addresses, escalation 

intervals, and escalation procedures?" 
Those skilled in the art will understand that thousands of other SLA questions 
can be implemented in a similar manner, in various sections and subsections. 
Such questions specify requested contract terms, which may later become part 
30 of the telecommunications contract. However, the SLA questions are not 
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necessarily so restrictive. While some or all of the questions may request a 
binary "yes" or "no" answer, others may invite comments, data, references, 
and any other information that may be useful to the customer in making a 
contract selection decision. 
5 RFP system 400 can be used for products and services other than 

telecommunications carrier services. For example, products such as computers, 
networking devices, telephones, and office equipment can be included in the RFP for 
bidding by interested vendors. Because some vendors sell both telecommunications 
services and other products (telephones, switches, modems, etc.), RFP system 400 

10 can also be used for soliciting bids on packages of telecommunications services and 
other products. As used herein, the term "commodities" shall mean products, 
services, or a combination thereof. 

In addition to the traffic forecast, SLA questions, and other information 
described above, RFP system 400 also prompts the customer to select the extent to 

15 which information about the auction and the bidding status will be disclosed to 

interested vendors (step 616). For example, the customer may choose whether to 
reveal the customer's name. The customer may also choose whether bidders will 
know each others' names. The customer is also prompted to choose whether to 
disclose to vendors the section and subsection rankings, question rankings, and overall 

20 rankings of their bids. RFP system 400 prompts the customer to select auction 

parameters, such as a starting date and duration of the auction, the vendors that will 
be invited to participate, whether vendor reference checking will be performed, 
whether overtimes will be allowed, the circumstances that will trigger overtimes, and 
the number and duration of overtimes (step 618). The auction parameters may also 

25 include reference checking for all interested vendors. 

If the customer desires vendor reference checking to be performed, a reference 
checking subsystem of the RFP system 400 prompts the customer for a required 
number of reference individuals that interested vendors will be required identify 
before bidding in the auction. The customer is also prompted by the reference 

30 checking subsystem to select and/or define reference feedback questions that the 
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reference individuals will be asked to answer. As with the SLA questions, the 
customer may choose to include the responses to the reference feedback questions in 
the calculation of vendor scores, and to weight the reference feedback questions in 
accordance with their importance to the customer. 
5 A verification routine of RFP web server 402 is activated by the customer 

after completion of the RFP to verify that all necessary information has been entered. 
If not, the verification routine flags the missing information and alerts the customer 
before allowing the RFP to be finalized. When the customer is ready to finalize the 
RFP and release it for bidding, RFP web server 402 prompts the customer to confirm 

10 that the RFP is ready for release to potential vendors (step 620). 

Again referring to Figs. 4 and 5, once the customer has completed the traffic 
forecast, SLA survey, and auction parameters (step 502), RFP system 400 generates 
an RFP web auction response template (step 504). The response template is then 
stored on RFP database 408 for later access via RFP web server 402 by interested 

15 vendors using vendor computers 420. Once the customer has confirmed a decision to 
release the RFP auction, RFP system 400 sends an email invitation to each potential 
vendor (step 506) . The email invitation includes a uniform resource locator (URL) 
that uniquely identifies a web page login into a reverse auction environment of RFP 
web server 402. The web page login prompts the interested vendor to input a vendor 

20 name and password that has been assigned to the vendor by RFP system 400 and 
supplied in the email in step 506. Immediately after signing on to RFP web server 
402, the interested vendor is prompted to agree to a nondisclosure agreement (NDA) 
and letter of intent (LOI) that include terms of participation in the RFP web auction 
(step 508). 

25 If the customer has opted for vendor reference checking to be performed, the 

reference checking subsystem asks the interested vendor to provide names and email 
addresses for the required number of reference individuals (step 509). The reference 
checking subsystem then generates email messages to the reference individuals, 
inviting the reference individuals to provide reference feedback on the interested 

30 vendor. The email requests include instructions and passwords for accessing a 
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reference feedback page of the RFP web site, where the reference individuals will be 
prompted to answer the reference feedback questions. 

After the interested vendor agrees to the terms of the NDA and LOI (step 508) 
and identifies the required number of reference individuals (step 509), RFP 
5 system 400 presents the RFP to the interested vendor for bidding (step 510). RFP 
system typically provides limited options for responding to the SLA questions- 
typically in the form of radio buttons and drop down menus. Freeform input is 
restricted to prevent interested vendors from flooding the customer with unwanted 
sales and advertising information. The interested vendor is also prompted by RFP 

10 web server 402 to bid on the various services and products included in the RFP. An 
email form within the RFP site allows the vendor to submit questions that are 
forwarded by RFP system 400 to the customer via email. 

RFP system 400 will save the accumulated vendor responses if the vendor 
chooses to exit the system prematurely, allowing the vendor to resume completion of 

15 the SLA questions and bids at a later time. Since the input is made via a secure web 
site, RFP system 400 also facilitates division of responsibility at the vendor for 
answering the various questions and providing the bid prices. A verification and bid 
submission security page allows final bid completion and submission to be controlled 
by only those persons at the vendor with the necessary bid submission password 

20 (which may be different from the account password). Upon completion and 

submission of a bid, the RFP system 400 generates a status email to the interested 
vendor that confirms receipt of the bid. The status email can, at the customer's 
option, include ranking information generated by a bid analysis module that analyzes 
the bid relative to other interested vendors and BOC database 406. Once the bid is 

25 submitted, the interested vendor can then review its bid, view its ranking on the RFP 
web site, and submit modified bids (step 512). Upon receipt of the bid, RFP system 
400 can also send a generic bid notification email to all of the potential vendors. The 
bid notification email does not identify the bidder, but gives the potential vendors an 
opportunity to respond with a more competitive bid. 
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As described in step 618 (Fig. 6), the customer can designate one or more 
overtimes 514 to extend the deadline for submitting bids beyond the scheduled auction 
end time. The customer can choose to have one or more overtimes triggered in 
selected circumstances, such as when multiple bidders have submitted competitive 
5 bids near the end of the auction. Overtimes are beneficial to the customer because 
they encourage bidding wars, which drive down prices. 

Upon completion of the reverse auction, a database update module of RFP 
system 400 compares the best bids for the various services and products included in 
the RFP against the corresponding estimated market rates stored in BOC database 406 
10 (step 516). If appropriate, the database update module updates BOC database 406 

with rates and other bid information. The customer has an opportunity to review the 
final proposals submitted by interested vendors and to review auction summary 
information, such as graphs of the bid prices over time (step 520). The customer then 
selects one or more of the proposals and contacts the submitting vendor(s) to negotiate 
15 and finalize one or more service contracts (step 522). 

It will be obvious to those having skill in the art that many changes may be 
made to the details of the above-described embodiment of this invention without 
departing from the underlying principles thereof. The scope of the present invention 
should, therefore, be determined only by the following claims. 

20 



